10.1 FHIR架构的应用
10.1.1 企业架构中的 FHIR及局限性
企业架构（Enterprise Architecture）是一个用于演进或维护存在的信息技术和引入新的信息技术来实现组织的战略目标和信息资源管理目标的集成的框架。可以想想，数字化转型一个对企业来说影响深远，牵连广泛的变革，基于企业架构的统筹规划和设计对于医疗机构的数字化转型具有良好指导作用。
FHIR并不覆盖企业架构的所有方面。根据 FHIR架构介绍的描述，FHIR的特性是平台相关的（Platform Specific），覆盖信息模型和行为模型视角的制品。对FHIR的支持能力将与其他视角的制品协作，如授权体系、功能规格、部署模型等，共同完成医疗机构的整体企业架构。
在FHIR的核心定义中，资源定义明确限定了协议涉及的实体集合，这些实体的内涵，以及这些实体与医疗行业流程中涉及概念的对应关系，为信息交互提供了语义统一的物理模型；而FHIR协议定义的多种交互手段，包括消息传递、API，则确定了该协议的接口手段，覆盖接口实现的需求。FHIR的这些特征为企业架构提供了可复用的制品，可在不同的企业和不同的交互场景中使用。但应用FHIR也需要在企业架构中对FHIR所需的约束进行支持。
另一方面，尽管基本的FHIR规范描述了一套资源、框架和API，在医疗卫生领域的许多不同情况下被使用。然而，随着国家、区域和机构间的医疗法规、流程、结算方式等具体需求的不同，FHIR规范在各个医疗生态系统之间存在着很大的差异。基于支持差异化场景的考虑，FHIR并不声称能够自动支持所有的医疗行业交互场景。相反的，FHIR一直强调其覆盖的是最常见的交互需求，它创建了一个共同的平台或基础，各种不同的解决方案都在此基础上实现。因此，这种规范通常需要进一步调整以适应特定的使用环境，这个调整的机制由Profile来完成。
就目前FHIR的发展状况来看，各国政府针对不同场景下的FHIR交互，将通过发布对应的Profile进行约定。举例而言，美国CMS，英国NHS都已针对机构间数据共享、医保支付和转移等场景定义和发布了多个Profile。这些Profile之间有交集，但也有彼此独立的部分。例如针对保险转移业务的Profile，其中的患者信息、就诊记录等临床信息与医疗文档交换的要求一致，但保险范围、报销清单等保险相关资源则为该Profile特定的资源。不同Profile在同一临床概念上绑定的术语也可不同。这样一来，基于FHIR的医疗信息交换引擎需要能支持多种Profile，并根据场景进行选择和应用。正如HL7 SAIF框架中所展示的，在平台独立（Platform Independent）的规约中，接口和服务的规约（Interfaces/Service Specifications）是构成企业架构行为模型的设计元素。
在应用FHIR的过程中，应当注意到FHIR协议本身并不能解决架构中的所有问题。因此，企业仍需要在交互、治理流程的梳理，安全与授权控制体系，部署架构设计等其他方面付出大量精力。另外，和采用其他标准协议的过程一样，应用FHIR也将不可避免地需要付出学习和迁移成本，尽管FHIR是一个免费、开放的标准，其学习曲线相较于HL7 V3来说将更平缓，在开源社区也有大量的组件支持，开发者仍需要花费相当的精力学习和理解FHIR的设计理念和应用原则，遵循实施指南（Implementation Guide）中阐明的约束，才能将FHIR应用在项目中。
本章将列出HIT发展过程中，FHIR能够发挥良好作用的应用场景，并结合诸位作者的经验，列出实现这些应用场景可采用的功能和技术架构。当然，面对HIT多种多样的需求和当前日新月异的技术发展，对于一个特定的问题，绝不会只有一种解决方案，本文中列出的架构也不是对特定问题的唯一解答。对于例如信息共享交换、数据存储和利用以及开放平台这样的高度多样化、差异化的需求，读者还可参考企业架构中提供给的方法论及工具，遵循符合自身需要的技术路径，才能实现数字化转型的各个步骤。
10.1.2 FHIR架构的应用方向
10.1.2.1 使现有解决方案支持FHIR
FHIR可用于轻量级或重量级客户端、推式或者拉式设计、发布/订阅、单体架构或微服务架构、中央服务器架构或点对点共享解决方案。使用FHIR 构建解决方案不会改变现有的开发流程，也不会强制使用特定的架构或技术堆栈，我们仍然可以继续使用常用的敏捷开发、TDD测试驱动开发、CQRS(Command Query Responsibility Segregation)、DevOps和持续集成等方式。那么如何在现有解决方案之上提供可互操作的FHIR API，以便使用者可以轻松理解和使用，以下给出了一种可能的FHIR 架构的示例。由于需要将现有的数据模型转换为合适的FHIR 资源，因此这种方法很大程度上会导致映射工作。这时我们可以使用 FHIR和专有API的混合模式，主要有几个原因，例如：
1) 后端（尚）不支持客户端所需的 FHIR 功能。
2) FHIR 标准规范中目前未找到描述需要的医疗领域或用例。
图10.1.2-1 在现有后端基础上的混合FHIR/专有API模式
这种架构模式下，其中的FHIR Adapter与FHIR API的部分我们有两种方式来实现。第一种方式是使用集成引擎来快速实现系统内部接口中的数据格式映射转换成FHIR资源，目前各医疗机构使用较多的集成引擎包括Lyniate的Rhapsdoy、InterSystem以及Odin Health的产品。这些医疗集成引擎产品均自带开箱即用的FHIR组件，允许实施人员快速开发定制基于FHIR标准的接口。基于集成引擎的整个开发过程中一般只需手动编写部分代码，大部分是基于GUI进行操作，可以让实施人员专注于工作流程的接口设计。通过这些内置封装简化的FHIR技术组件，让整个解决方案快速具备能够提供符合 FHIR互操作性的API，对后续增加的模块只要满足FHIR标准，不需要修改应用程序，即可实现软件的即插即用，大大降低了实施部署的成本。这种以集成引擎为中介的方式让项目实施改造更为轻松，为用户提供更快、更流畅的体验，不需要将大量时间花在代码技术实现上。
第二种方式是我们可以选择自主开发，让使用旧标准的老式系统仍可以在健康信息数据生态系统里交换信息，同时兼顾最新的FHIR标准应用能力。目前常用的有基于Java语言的Smile CDR公司提供的HAPI FHIR开源框架、基于.NET平台的firely-net-sdk的开发包等。通过使用这些开源的集成框架让我们的医疗数据转化映射成FHIR标准数据，同样可以实现基于FHIR资源的电子健康信息交换、共享。
当然，不论我们采用上述两种方式的任何一种进行实现，使现有解决方案具备FHIR访问的能力的途径都需要了解解决方案对FHIR标准的预期用途、将现有解决方案的数据模型映射到合适的资源，同时选择合适的交互范式来构建解决方案。
10.1.2.2 新建基于FHIR的解决方案
当我们需要重新构建基于FHIR的解决方案时，则从FHIR 作为平台设计规范开始来创建 FHIR原生解决方案。在这种架构模式中，FHIR作为系统的中心设计元素，直接存储在SQL或 NoSQL后端数据存储中，同时FHIR有许多强大的功能来一起构成一个平台解决方案，包括：
1.Structure Definitions（结构定义）：描述FHIR 结构本身。结构定义用于描述 FHIR标准规范中定义的内容，比如资源、数据类型和底层基础设施类型。
2.Search Parameters （搜索参数） ：描述FHIR服务器支持的搜索功能类型。
3.Capability Statement（能力声明） ：FHIR服务器向其他软件系统传达其能力集的一种方式。客户端可以简单地检查 FHIR 服务器的 Capability Statement 以确定，例如，是否支持特定的 FHIR 资源，以及它是否可以预期读取和写入这些资源到服务器。
4.Healthcare Domain Model（医疗保健领域模型） ：一组定义明确且经过深思熟虑的资源，用于描述医疗保健领域。比如患者、药物、过敏等。
5.Extension（扩展）：一种扩展或添加到 FHIR 资源或添加到 FHIR 资源中特定元素的内置方式。
6.Profile（规范）：FHIR是一个平台标准规范并且非常灵活，所以经常需要指定要使用 FHIR 规范的哪些部分。使用规范配置文件，解决方案的设计人员可以指定使用哪些资源元素，在某些元素中使用哪些术语，以及如何调用 API等。
图10.1.2-2 基于FHIR的原生架构模式
以上是 FHIR 的部分特性，有了这样一套定义明确的平台结构，我们可以构建一个基于 FHIR 的全新原生解决方案。整个模式采用逻辑分离构建，使开发人员能够灵活地修改其实现方式，并根据需要扩展其功能。实现的架构逻辑是：我们从 FHIR 结构定义开始，内部使用 FHIR 作为底层域模型，用来生成对象模型、相关表结构和数据类型，使用FHIR定义地搜索参数来创建必要的索引，以非常快速和可伸缩的方式支持FHIR搜索。在数据访问层实现与FHIR 资源的存储、索引和检索相关的所有数据库业务逻辑。业务逻辑层则根据医疗机构的需求将这些资源进行组装，对业务流程进行编排，最终构建以RESTful API范式或其他受支持的范式（如消息、文档或服务范式）等常见的形式提供服务的FHIR API。
FHIR架构的应用方向一种是将FHIR API添加到现有解决方案中，这是考虑使用FHIR时最常用的方法。另外一种是使用FHIR标准规范及其所有表现力来创建FHIR 原生解决方案。原生解决方案提供了极大的灵活性、面向未来的能力、开发和集成的速度，并且是处理医疗保健数据的一种很有前途的新方法。